1. Field of the Invention
This invention relates in general to computer-implemented database management systems, and, in particular, to a more efficient database recovery system.
2. Description of Related Art
Databases are computerized information storage and retrieval systems. A Relational Database Management System (RDBMS) is a database management system (DBMS) which uses relational techniques for storing and retrieving data. Relational databases are organized into tables which consist of rows and columns of data. The rows are formally called tuples. A database will typically have many tables and each table will typically have multiple tuples and multiple columns. The tables are typically stored on random access storage devices (RASD) such as magnetic or optical disk drives for semi-permanent storage.
RDBMS software using a Structured Query Language (SQL) interface is well known in the art. The SQL interface has evolved into a standard language for RDBMS software and has been adopted as such by both the American National Standards Institute (ANSI) and the International Standards Organization (ISO). The SQL interface allows users to formulate relational operations on the tables either interactively, in batch files, or embedded in host languages, such as C and COBOL. SQL allows the user to manipulate the data. The definitions for SQL provide that a RDBMS should respond to a particular query with a particular set of data given a specified database content, but the technique that the RDBMS uses to actually find the required information in the tables on the disk drives is left up to the RDBMS. Typically, there will be more than one technique that can be used by the RDBMS to access the required data. The RDBMS will optimize the technique used to find the data requested in a query in order to minimize the computer time used and, therefore, the cost of performing the query.
Applications (i.e., application programs) communicate with relational databases using the Structured Query Language (SQL). SQL statements are issued to the RDBMS, which executes the SQL statements to access a relational database. The SQL statements received from an application are executed within a “unit of work”, which is a collection of related SQL statements. Once the SQL statements are executed, they are either “committed” (i.e., the changes made by the executed SQL statements is made permanent in the relational database) or they are “rolled back” (i.e., the changes made by the executed SQL statements are removed, returning the relational database to the state it was in prior to execution of these statements).
One important aspect of managing a RDBMS is creating backups of the objects to insure data integrity in the event of crashes or other computer misfortunes. Conventional systems often generate backups in a nondisruptive manner by allowing full read/write access to the data being concurrently copied. By making nondisruptive backups of all of the objects conventional systems necessarily create “fuzzy backups” (i.e., backups containing uncommitted data) since one or more objects may be altered while being processed by an application during the backup operation. In other words, the backup does not contain all of the current object information.
In attempting to resolve this fuzzy backup problem, conventional systems perform a recovery procedure that retrieves objects or object data that was not initially recorded in the backup copy. Conventional systems, however, are not capable of selecting or determining which objects have been altered since the last backup operation. Therefore, in order to recover the most current objects, conventional systems resort to taking the system back to a point in time and recover all of the objects rather than only the objects that were actually altered.
The conventional systems described above utilizes what is generically referred to as a two-phase commit system. This system is based on points of consistency. A point of consistency is a point in time at which the data in the database is consistent. The two-phase commit system ensures that either all or none of the databases are updated, and, thus, ensures that the databases remain synchronized. More specifically, a first point of consistency exists when a COMMIT statement is invoked. A new point of consistency is established when the unit of work completes and the COMMIT statement has fully executed. The work completed or change implemented during this COMMIT interval is referred to as a unit of recovery (UR). Each UR represents, for example, an altered set of data or an altered object. The COMMIT statement ends a UR and commits the relational database changes that were made in that UR. While changes remain uncommitted, i.e., while an object or data is in the process of being altered, other application processes are unable to perceive these objects or data. Once committed, these database changes are accessible by other application processes.
Since conventional systems perform the backup and recovery tasks by simply copying all of the objects as they existed at a certain time, some of the object or data changes copied to the backup are uncommitted, resulting in fuzzy backups. Subsequent recoveries cannot be in general accomplished by only restoring the backup copies. Thus, in order to ensure that an object contains current data, conventional systems copy all of the objects from the backup copy and scan and apply the database log, which records all of the activities relating to a database, to identify what changes were made to that object. Reviewing the database log for each object and applying the appropriate changes to a backup copy can be very time consuming and expensive resulting in inefficient database recovery procedures.
In addition to copying all of the objects and applying the database log to these objects, an additional shortcoming of conventional systems is that they must backup objects at a “quiesce” point in time, i.e. the time when there are no uncommitted URs in the system. Establishing quiesce points is normally very disruptive for everyday operations. In order to create a quiesce point, the system suspends the creation of any new URs until all URs already started are committed. In the environments with long running URs, the attempts to create a quiesce point can bring the system to a standstill.
These shortcomings are further amplified when systems utilize multiple objects or large objects. For example, in environments with complex and practically unknown semantical integrity rules such as SAP® R/3®, Peoplesoft®, Baan®, etc., the only safe way to recover data or objects from a prior point in time is to bring the entire system, i.e. all the associated data and metadata back to that point in time. These systems consist of a large number of objects (tens of thousands) and often a large amount of data (hundreds or thousands of GB). System recoveries based on the ‘fuzzy’ backups of these systems are even more expensive and time consuming. Consequently, users may experience longer system down time and data recovery, system disruption, and increased costs of performing database backups and recoveries.
Accordingly, there is a need in the art for a framework for managing backup and recovery procedures in a database that identifies individual objects that have been altered, brings back the system to a particular time to recover those identified objects, and does so irrespective of the presence of uncommitted URs and quiesce points. That is, there is a need in the art for a more efficient object recovery system that can recover objects such that recovery times, database log analysis, system down time, and object recovery costs are minimized.